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Publisher's Introduction; 


Here you have the April 1975 issue of ECS, complete and unexpurgated. The main 
theme of this issue is the introduction of the "SIRIUS-MP" language as a notational form 
for expressing programs. The idea of SIRJUS-MP is to slightly generalize the low 
level code approach to program notation so that it will be fairly expedient for subscribers 
to hand "cross compile" programs on whatever variation of the "home brew computer" 
concept they have implemented. The variations on this theme include... 

1. The SIRJUS-MP Language. . . This article, beginning on page 2, is a first 
statement in these pages of some of the concepts involved in the language. 

It also provides information useful in understanding the several SIRIUS examples 
found in this issue. 

2. BOOTER; An "Emergency" Bootstrap Loader.,. It is common knowledge 
what to "do when the lights go out. " But what do you do after the lights go out 
when your computer and volatile software were on the same power source as 
the lights? Turn to page 11 for a description of an emergency bootstrap loader 
concocted one weekend to combat electron deficiency anemia. 

3. IMP Extensions For Tape Interface Control (Continued...) In the last issue, 

I did not quite fit all I intended to print within the confines of 28 pages. The re¬ 
maining segments of the tape interface are presented in a SIRIUS fashion along 
with the equivalent 8008 code, beginning on page 14. 

4. Comments on the ECS-8 Design; Turn to page 19 for a short note on one 
aspect of the ECS-8 design which I should have pointed out in the March article, 
and was the source of a complaint from my brother Peter Helmers. 

5. Notes on NAVIGATION IN THE VICINITY OF Qg-AQUILA ... #1. So, you 
went out and got yourself an Altair computer? Now what? Turn to page 20 for 
the fir st in a continuing series of articles on the use and abuse of the Intel 8080 
instruction set in an ECS context - with occasional intermingled information on 
hardware interfaces to be supplied from time to time (but not this time however.) 

6. Erratum; Turn to page 24 for a short note about an ECS-7 diagram error. 

7. A Note Concerning The Motorola 6800 MPU; Also on page 24 is a short note 
concerning the use of the M6800 in an ECS context, now possible to contemplate 
on a practical basis in the near future. 

This issue is going to press April 21 1975 . The next issue is fairly well defined as of 
this date, and will include: an article by subscriber James Hogenson concerning the 
design of a unique oscilliscope graphics interface featuring a 4096 point (64x64 grid) 
matrix of spot locations; a continuation of the software discussions begun in this issuej 
and possibly a review of one or two tools which will be of interest to readers. 

Carl T. Helmers, ttJr. 

_ Publisher April 20 1975 


1975 M. P. Publishing Co. All Rights Reserved. 
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The SIRIUS-MP Language... 

an approach to machine independent low level code. 


This issue begins a subject which will continue in the pages 
of ECSfor some time to come: the subject of expressing pro¬ 
grams in a fairly well defined low level "language" which is in 
principle independent of any particular microprocessor or other 
small computer you might have. This will facilitate your use 
of published programs written for an 8080 if you own an IMP-16, 
or programs written for 8008 if you own an M6800, etc. - pro¬ 
vided the programs in question are expressed in the SIRIUS way. 

The name I have chosen for this language is "SIRIUS-MP". 
The SIRIUS is a combination of an April pun and the following 
input: if Altair is the brightest star (visual magnitude) in the 
constellation Aquila, then let me modestly name this mode of 
program expression after the brightest star in the sky, the 
star OC-Canis Major or SIRIUS. So, if you are SIRIUS about 
Altair (or other computers available inexpensively both now and 
in the near future) you will find this series of articles illxunin- 
ating. So much for the advertisement now to turn to some 
information content. . .. 


WHAT IS A COMPUTER LANGUAGE? 

The answer to this question (as is always the case with complicated subjects) can 
range from the superficial to the formal mathematical intricacies of compiler-writing 
and language design. Since this publication is not a technical journal on software eng¬ 
ineering, it must necessarily leave out a lot of the detailed information on the subject, 
to concentrate on the application of the concept. (Upon sufficient interest - one inquiry 
I'll spend an evening sometime and compile a bibleography on the subject of compilers 
and computer languages. ) With this disclaimer I'll proceed to the subject of computer 
languages in the context of a home brew microcomputer system. 

Starting from first principles, what is a "language" (eg: English, German, Pidgin, 
integral calculus, set theory) in general? I'll confine the subject arbitrarily to the 
concept of "written languages" and put forth the following formulation: 

A LANGUAGE IS A HUMAN INVENTION FOR THE PURPOSE OF 
EXPRESSING THOUGHTS. 

This definition is filled with implications: language is an invented technology (probably 
the first) of humans (or other critters. ) language is utilized in communicating thought! 
between individuals. Language is appropriate to thinking beings. Now what could 
this possibly have to do with your urge to program and use a microcomputer ? 
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A fair amount of course! The specific application of the language concept to the 
problem of programming a computer is the concept of a "programming language." 

The specific part of this application is the limiting of computer languages to certain 
classes of thoughts... 

A COMPUTER LANGUAGE IS A HUMAN INVENTION FOR THE PURPOSE 
OF EXPRESSING COMPUTER PROGRAMS. 

Just as there are nuznerous variations on the "natural language" concept (Eg; ENGLISH), 
the diversity of human thought has lead to a wide range of computer langiiages from the 
most general to the specific and application oriented. In each such language, the 
author(s) have selected a set of elements needed to solve the particular problem and 
combined these in a (more or less) self consistent manner and come up with a solution 
to the problem of expressing programs of a particular class. 

The creation of a programming language for the particular case of a microprocessor 
system in the "homebrew" (ie; limited hardware) environment is the object of this 
series of articles in ECS. When you design and or build a hardware system, your first 
problem is solved - a computer that "works". To get beyond this first phase the problem 
becomes developing the programs enabling your system to do interesting things. A 
language can be used for ^3 purposes in the process of programming your computer: 

a. An appropriate language enables you to abstractly specify a program in 
a first iteration of design without worrying "too much" about details. Get 
the control flow figured out first, then worry about low level subroutines! 

b. An appropriate language will enable you to hand compile programs ex¬ 
pressed in that language for use on your own computer, even if the program 
was developed and debugged on another computer. You know the "algorithm" 
works even though you have not yet translated it to your own use. 

c. A language appropriate for the home microprocessor will be of sufficient 
simplicity to allow hand compilation or compilation by a very simple compiler. 

These considerations - the definition of a "home brew computer" context - are a major 
input into the design of the SIRIUS -MP method of program expression. 


SETTING THE PROJECT IN CONTEXT; 

HOW WILL SIRIUS-MP COMPARE TO EXISTING LANGUAGES? 

The approach taken in the choice of elements for the SIRIUS-MP language is that of 
a "pseudo assembly language. " An assembler is the simplest of all software developme 
aids to write, so this choice tends to satisfy criterion "c" above. But what about "a" 
and "b".^ This is where the "pseudo" part enters the description; it is a language 
one step removed from the detailed instruction level in many of its operations. SIRIUS 
is an assembly-type language for a class of similar machine architectures - with opera¬ 
tions found in general on such machines forming its "primitives. " The subject of addres 
resolution is left intentionally non-specific and symbolic so that variations in the way 
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<i3,t3, is &ccessecl csn be left to the h3.nd or mcichine-aided process of generating code 
for your own system. Many of the statements written in this form will generate only 
a single instruction on the "object" machine - but others will require a series of sever¬ 
al instructions to specify required actions on a given machine. It is my intention to 
include within this "pseudo assembly language" concept several programming constructs 
borrowed from high order languages in current usage - but stripped of the complex syn¬ 
tax of a true high level language and specified in the simplified form of the SIRIUS-MP 
syntax, such as it is. This adaptation of a language to a specific purpose and class of 
users is a widespread practice in the compiler/language design business. Several ex¬ 
amples come to mind of specific languages for specific usage contexts : 

t 

XPL, - this language is the compiler-writer's language to a great extent. It 
is a specific and limited subset of PL/1 by McKeeman, Wortman and 
Horning which isdocumented in a book entitled " A Compiler Generator. " 

The adaptation here is to concentrate on those features necessary for the 
writing of compilers and exclude all else. (Intel PL/M is very close to XPL) 

HAL/S - this language was developed for guidancej navigation and control appli¬ 
cations of NASA by Intermetrics Inc. , the author's employer of several years. 
HAL/S is specialized to include the vector and matrix data forms used in space¬ 
craft navigation - and to provide highly visible "self-documented" code which was 
not possible in the assembly language style approach used in the Apollo program. 

SNOBOL - here is a language which is primarily oriented to "string handling" 
programs - a very broad range of applications, in some sense including 
the writing of compilers as well. 

ALGOL - this language is the antecedent of many currently used languages , 
whose original intent was a specialization in generality - the ways in which 
algorithms could be best specified, in the abstract form. 

These languages are all examples of much more extensive and complex methods of 
program expression from a compiler writer's standpoint - although from the user's 
standpoint they are orders of magnitude easier to program with than doing the equivalent 
in a low level "pseudo assembly language" or formal assembly language for a specific 
machine. It is the problem of generating code by hand or with minimal program aids 
which limits the possibilities of SIRIUS program specifications to the low level approach. 


WHAT ARE THE COMPONENTS OF A COMPUTER LANGUAGE? 

For those readers with a software or computer-science background, this dis¬ 
cussion is in the nature of a review. For readers with litlie programming background 
this will present new information. 

When you build a computer from a kit or from scratch, your problem is to put together 
a set of hardware components according to a certain system design ( usually inherent in 
the microcomputer chip design) such that all the components play together as a working 

system. At a level of abstraction far removed from - yet still within the context of - 
the detailed hardware, a language for computers is also a construction of component parts 
which must "play together" according to a particular design if the language is to be 
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useful as a means of expressing programs. At the most abstract level of discussion, a 
language consists of two major component parts designed to provide an interface between 
a human being's thoughts and the requirements of computing automata. These are: 

SYNTAX: - this component of the language is the set of rules concerning the 
correct formulation of basic "statements** or "expressions** in the language 
in question. 

SEMANTICS; - this component of the language is the set of rules governing the 
intelligible combinations of syntax elements - the combinations which produce 
a well defined and translatable meaning which can be used in turn to generate 
machine code for some "object" or "target** machine of a compiler. 

The syntax and semantics of a programming language can be chosen with a somewhat 
ill-defined border: one of the major trade-offs to be done in designing a language and 
associated compiler is deciding how much of the work is to be performed by the syntac¬ 
tical analysis and how much is to be left to semantic interpretation. At one extreme there 
is the complex syntax of a high order language in which much of the semantic intent of 
a statement is inherent in the syntax used; at the other extreme there is the case of the 
simple "assembly language" style of syntax in which very little function is inherent in 
the syntax - which merely distinguishes labels, operators and operands. 

SIRIUS-MP is at the "assembly language" end of the trade - its syntax is kept simple, 
so that a minimal compiler (or hand compilation) will be used to translate it to machine 
codes, and the semantic interpretations are largely look-ups based on the specific content 
of the statements coded in a program, with very little variation on certain basic forms 
for operands and operators. 


SPECIFICATION OF SIRIUS-MP: 

The specification of a language can be a very formal and very dry process. A languag« 
specification is ultimately required in order to clearly convey the meaning of statements 
coded in the language, the legal variations on such statements, etc. etc. A certain level 
of consistency in specification is required, for instance, if I want to write a compiler 
for a given language. At the present time, however, my reasons for formulating SIRIUS 
are much less demanding than the formal specification of a language: I am interested 
in creating a method of describing programs which will be heavily commented and used 
principally for publication in ECS (and possibly other publications.) Thus the specifica¬ 
tion is left in a fairly "soft" form for the time being within a general framework describee 
in this issue. The time for a formal specification will be the day I sit down and write 
an appropriate compiler - or a reader decides to do so through impatience and the desire 
to write one for publication (with the usual royalty of course. ) 

In lieu of a really formal specification of the SIRIUS-MP language, the next few pages 
contain an informal description of several notational devices employed in the examples of 
SIRIUS-MP programs in this issue, and comments on why the forms are used. The areas 
covered are: STATEMENTS, ADDRESSING & REFERENCE, DATA REPRESENTATIONS, 
and OPERATIONS. Omitted in the present discussion are several languages forms to 
be described at a later time, including certain "structured programming" concepts and 
details of argument/parameter linkage conventions for subroutine calls in SIRIUS-MP. 
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STATEMENTS ; 

The basic notational unit of a program which is written in SIRIUS-MP is the "state¬ 
ment. " The statement concept embraces the others mentioned on page 5, as can be 
illustrated by the following prototype format: 

L.ABEL: 

TARGET OP SOURCE * COMMENTS \ 

As in most decent assemblers, the intent is to make the statement "free form" and 
thus requiring no fixed column or line boundaries. Hence the following devices are 
used as a part of the syntax: 

The end of a statement is indicated by a (semicolon) as in a host of 
PL./1-like languages.* 

A label, if present, is distinguished from the first (TARGET) operand or 

the operation mnemonic (OP) by a (colon). With this choice of trailer, 

labels must not duplicate any operation codes (OP) which can have similar endings. 

An asterisk (*) is shown as a separator between the main part of the state¬ 
ment and the comments field at the right. 

For examples of the use of this format, see the several program listings included with 
this issue below. The fields in this prototype statement are as follows: 

LABEL - this field (and its ":" separator) is optional and is used to define a symbolic 
program label. A label is ultimately required to define all symbols used in a pro¬ 
gram with the exception of certain implicitly defined symbols such as CPU registers 
and flags. 

TARGET - this field (optional) specifies a symbolic reference or absolute address for 
the memory location (s) or I/O devices which will receive data as a result of an op¬ 
eration. Certain operations will not require a target field for proper notation. 

OP - this field is required in order to specify an "operation" to be performed at some 
time. Certain operations will correspond to executable code in the translation. Others 
will be used to reserve storage and indicate aspects of the program generation pro¬ 
cess. 

SOURCE - this field is required to specify a minimum of one operand for each opera¬ 
tion. Its format will vary depending upon the type of operation intended - variations 
will include various forms of symbolic reference as well as compound forms used 
to control functions such as "FOR" loop constructs or "IF" statements. 

COMMENTS - here the field intent and use is fairly obvious - to explain what is going 
on it is useful to make notations. 

* Note: The alternate form of statement boundary indication to the ";" is to start 
a new statement on a new line. The examples in this issue all omit the ";" specified 
above - a detail to be corrected in future issues. 
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ADDRESSING AND REFERENCE; 

For those individuals who have experience with high level languages (eg; FORTRAN, 
COBOL, PL/1, ALGOL, BASIC etc. ) the common experience is to blithly go ahead and 
program an application with the various "variables” declared within a program by impli¬ 
cit or explicit means. This approach is appropriate for a high order language in most 
instances because the problem of addressing and referencing.data in the computer has 
been solved in a fairly general and quite reliable manner by the compiler writers. When 
the time comes to drop down one level of abstraction to the assembly level, the problem 
of addressing has to be again considered in a more explicit manner since many more 
details of machine architecture are inherent in such progrannming. In deciding what 
forms of addressing and data reference to include in SIRIUS-MP, the low level approach 
is augmented by several methods of more abstract reference. The following are some 
key referencing concepts: 

ABSOLUTE ADDRESS; The concept here is of a fixed location in the memory address 
space of the computer or a given I/O instruction channel designation. In a system 
bxiilt around a Motorola 6800 for example, most I/O operations will be carried out 
with reference to absolute addresses for the I/O interface memory locations - at 
least in simple programs this will be the case. In the INTEL or National IMP-16 
architectures esqjlicit choices of I/O channel require designation of numbers, often 
in an absolute form. 

EXAMPLE; The Octal expression 020023 could represent 

an absolute address. 

SYMBOLIC ADDRESS; The concept here is to reference the name of a data item in an 
instruction rather than its actual address. In principal all such names map into a 
fixed and unique address at execution, either through the operation of a compiler's 
address resolution or through a run time lookup mechanism such as the SYM routine 
used in the previously published ECS 8008 software. In SIRIUS notation, a symbol 
is defined by its appearance as a LABEL of a statement, or its existence as a pre¬ 
defined entity such as a register designation . 

EXAMPLE: Given label ANYSYM, a reference in some other (eg: assignment) 
statement might be; 

ANYSYM =; 0 (as the TARGET operand.) 

INDEXED SYMBOLIC ADDRESS; The concept here is to reference the starting loca¬ 
tion of a block of memory by the first symbol involved, and to indicate an offset 
(from zero up) in bytes by a second symbol or literal in parentheses following the 
first. Thus: 

ANYSYM(OFFSET) is a reference to the location ANYSYM 
plus the current value of OFFSET when the statement is 
executed, 
or 

ANYSYM(23) is a reference to address ANYSYM plus 23. 

An alternate form of expression for this would be to show an addition ( + ) operator 
rather than use a FORTRAN or PL/1- like subscript reference with parenthesis. 
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SPECIAL SYMBOUC ADDRESSES; Here the concept is the notation of certain symbols 
with a fixed meaning, which in an assembler would effectively become "reserved" 
symbols not subject to redefinition. The forms used in the listings in SIRIUS in this 
issue are the following ; 

W(ANYSYM) means "the whereabouts of ANYSYM" and is the notation used 
to indicate a reference to the absolute address of the symbol. 

M(ANYSYM) means "memory reference to the location found in the value of 
ANYSYM." This is the basic "pointer" form used, and will assxune that 
the value in ANYSYM is a full address (eg: 16 bits for most machines. ) 

T(ANYJMP) means "the address portion of a j\amp instruction at ANYJMP". 

This notation was introduced to allow the equivalent of a FORTRAN 
assigned GO TO to be used by altering a jump instruction. 

A, B, C, D, E,H, L are symbols used freely to represent registers on the Intel 
8008 and 8080 type of machine architectures. In translating this reference 
to a Motorola 6800 or National IMP-16, or other computer architecture, 
an appropriate software equivalent would be used if registers 

are not available. 

L(ADDRESS), H(ADDRESS) are used to reference the Low and High order portions 
of a full address (eg: 14 or 16 bits) on typical microcomputers when it is desire 
to examine only one byte. This is especially useful as a notation for the Intel 
architectures, but the same functional meaning goes on other machines. 


The various forms of addressing and reference described can be used to specify the 
"operands" - SOURCE and TARGET - of a statement. The concept of a "SYMBOL" 
is the generalized idea of one of these forms of reference (excluding absolute references. 
A "symbol table" for a program is a list of such symbols, usually including some 
additional information about the item. In a future article on the hand generation of code 
this concept will be explored in more detail. 


DATA REPRESENTATIONS: 


A "data representation" is a method of conceptually treating a group of data bits in 
the storage of a machine, and is.usually fairly dependent upon hardware features of a 
given machine. The basic data representation of all the extant S^bit microcomputers is 
the 8-bit binary integer (two's complement is the rule. ) This is augmented in certain 
machines such as the 8080 and the 6800 by a limited set of 16-bit operations implemented 
to handle address calculations. For the 16-bit microcomputers and minicomputers, the 
word length as a rule sets the basic representation as a 16-bit integer, although smaller 
8 bit quanta can usually be employed. This immediately suggests that the basic assump¬ 
tion to be built into SIRIUS-MP is that data ought to be operated upon in 8 and 16 bit 
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quanta. This will prove a useful decision for most processors likely to be in common 
use by readers of this publication (if there is enough interest. I'll make some comments 
at a future time on adaptation to 12-bit machines such as the DEC PDP-8 and its imita¬ 
tors. ) The two representations are thus (pictorially) . .. 


MSR _ LSB 

I I I I < I I 
7 6 5 4 3 2 1 0 
8-bit integer 


MSB 


LSB 


I I I I I I I f I I I I I I -L 


15 141312 11 10 9 8 7 6 5 4 3 2 1 
16-bit integer 


The fact that there are two possible ways to reference integers built into the hardware 
operations of the typical 8 and 16 bit microcomputer formats, (8008 excluded) leads 
to a desire to specify a notation for the length of data involved. I could choose among 
two basic alternatives in this area: 


a. Specify data type in some form of declaratory way. This would be analogous 
to an XPL statement such as "DECLARE X FIXED;" or a FORTRAN state¬ 
ment such as "INTEGER X". 


b. Specify data type(length) as a part of the choice of operands used. Here the 
information on length of operations is specified when the data is used - thus the 
program has a bit of extra redundancy in its notation (the extra characters needed 
to specify this type information) but the operations performed are much more 
visible at the local level. 

The choice I made was for the second alternative, primarily to reduce the need for a 
symbol table to the barest minimum of information - consistent with the simplifications 
needed for a compact assembler or hand compilation. A secondary reason is the one 
stated in "b" - local type indications give a better documented program. In the integer 
operations used by programs in SIRIUS, a single colon (as in "AND:") is used to indicate 
where an 8-bit operation is involved, and a double colon (as in "AND::") is used to 
indicate the l6-bit form of an operation. A final comment on integers: where a signed 
integer representation is required in two's complement notation, the sign of the number 
is represented by the most significant bit ( bit 7 of length 8 words, bit 15 of length 16 
words. ) This is the bit tested by the "S" flag on the various microcomputers. 


Byte String Data : One additional data type will be required for programming the 
various microcomputers using SIRIUS-MP. This data type is the generalized concept 
of a "byte string. " The representation is 

designed for manipulation of blocks of data in 
memory, in a form consisting of a length byte 
at the "anchor" (starting address) of the string, 
followed by from 0 to 255 data bytes at consec¬ 
utive addresses. This is a format which is iden¬ 
tical to that used in many byte oriented compilers 
(eg: XPL) and is a virtual necessity for handling 
character texts. Applications will not be restric¬ 
ted to character texts, however, for one partic¬ 
ular use could include variable length decimal 
arithmetic using packed BCD byte strings. 
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Byte strings are most conveniently handled on computers which have byte addressability 
of memory locations - eg: the IBM 360/370 series as well as the smaller ( 8080,8008, 
6800) microcomputers. For 16 bit minicomputers and microcomputers, the concept is 
still useful, but requires explicit address calculations as a part of unpacking and manip¬ 
ulating two bytes per word. Operations on byte strings will use the notation of a number 
sign "#" to indicate the variable number of bytes involved. 

OPERATI ONS: 

With the above introduction regarding data representations, it is now possible to 
consider the basic operations possible. The list here represents those used in the nota¬ 
tion of the programs in this issue. In a later issue I'll expand the explanations of some 
of these operations and corresponding machine code for typical machines. There 

are also several operations which I have not used in the notation of the current set of 
programs, but which will be the subject of future notes in this area. The following 
is a list of the operations used with program notation in this issue, omitting the type 
indicators : 


AND 

GOTO 

INPUT 

Assignment{ = ) 

HALT 

lOEXCH 

CALL 

IF 

KEY WAIT 

CLEAR 

IFNOT 

OR 

DECR 

INCR 

OUTPUT 


The operations AND, OR, GOTO, HALT, INPUT and OUTPUT all have direct ana¬ 
logs in the CPU operations when 8-bit quantities are used with machines such as the 
8008, 8080 or 6800. The examples' 8008 generated code versions illustrate one such 
representation. Some further notes will help illuminate the code generation process for 
the other operations. 

For all operations which have direct analogs in the machine architecture, the code 
used for the machine level version must consist primarily of establishing the address¬ 
ability of operands (source and target) and then execution of the operation. This process 
is illustrated in the several examples. For 8 bit machines with 16 bit operations, the 
code generated must be generalized to 16 bits - for the 8008 this is done in the illustrated 
programs by appropriate subroutines for increment, decrement and comparison, so code 
generation consists of writing down machine codes for a subroutine call and argument 
linkage. 

Assignment always will map into a sequence of operations needed to move data from 
the source to the target. The 8008 generated code of these examples is an extension of 
the previously described symbol table mechanism for address lookup (see February 1975 
ECS. ) For 16 bit quanta this process can often be done using a CPU register pair for 
the 8 bit machines, but will invariably require a subroutine 'vdien byte strings are involved. 

The IF statement form used in the examples is found in both a negative and positive 
sense. In either case the TARGET (lefthand) operand is the place where execution will 
go if the condition tests true. Two forms of the condition (S OURCE) operand are used: 
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Flag Reference; Here the intent is to use a mnemonic key word, 
for example "ZERO** to reference one of the CPU flags of a typical micro 
after an instruction which might alter such flags. 

b. Tests; Here the intent is to specify two operands symbolically which 
are to be compared. I have grouped such references in parenthesis to sim¬ 
plify mechanical interpretation by a compiler, and have used the assignment 
symbol ** = ** with its length code with the usual duplicity to indicate the compar¬ 
ison test operation. 

A disclaimer is appropriate at this point - I am not satisfied with the IF condition test 
format illustrated in these examples of several programs, and will be experimenting with 
some alternatives. 


GENERATION OF CODE: 


The semantic intent of the language forms used to represent the several programs in 
this issue can be deduced from the comments in the listings and the general descriptive 
information in the previous pages. One remaining problem is the generation of code. 
For the time being, I am limiting information on this (very large) subject to the exam¬ 
ples illustrated below for an 8008 case and the notes accompanying the examples. I 
think there is sufficient information content to facilitate interpretation and generation 
of corresponding machine code for processors such as the 8080 (very close) or the 
6800. 


BOOTER; AN "EMERGENCY** BOOTSTRAP LOADER 

The first example of a SIRIUS-MP program is a short and self-contained program 
called **BOOTER. ** All programs ultimately solve problems. This particular program 
solved a problem which I had one weekend, and served as an **acid test** of the utility 
of the ECS-8 tape interface. As soon as I had the interface software up and running (the 
dump portion presented in March ECS*s pages) I began dumping the entire CPU software 
load to cassettes at regular intervals as a **failsafe** against Boston Edison*8 next power 
failure. The planning fot that contingency - which by the way did happen in an ice storm 
in January to my consternation - paid off in a different way; I made the foolish mistake 
of turning off the power via a switch on my bench, now taped over solidly. Since I was 
working on SIRIUS-MP as a program writing tool, I took the opportunity to test out the 
expression it provides by writing the BOOTER source program appearing at the top of 
the next page. I won*t claim perfection, however the original form of the program was 
essentially the same as the listing illustrated. 

Loading is accomplished as follows: in the tape format described in the last issue, 
the first legitimate data is the length code (two bytes which I knew had **007** and ••377M 
values for my tapes.) Since none of the tape spacing and preparation routines of the IMP 
program would be available in the blank computer memory being bootstrapped, the only 
way to synchronize tape data with the program was to listen continuously for the **007*' 
character (state 1, LOOKFIRST tests for "007"), then check for a succeeding ''377** 
byte (state 2, WEL.LMAYBE tests for "377"), then commence loading bytes starting at 



OiHCVJ jJAA'O r^ CO O iH C\J r^^Xrv'O c>^co o o 

H CNJ yO t*-CO a* i-liHrHi-4Hi-*iHr^ r-tr-lC\JCVJ(\J OJCNiCViCVi rUC\J(\J<v\ 
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The BOOTER program, listed i n SI RI US - M P. . . 


HOOTER: 


B 

=; 

1 

X 

=:: 

2000 


OUTPUT 

377 


CLEAR 

A 

A 

lOEXCH 

k 

BLOOP: 

A 

=: 

27 

A 

lOEXCH 


A 

AND; 

140 

BLOOP 

IPNOT 

(A=:lkO) 

GETCHAR: 

M(X) 

INPUT 

2 


DECR: 

B 

LOOKFIRST IP 

ZERO 


DECR: 

B 

WELLMAYBE 

IP 

ZERO 


DECR: 

B 

PORSURE 

IP 

HALT 

ZERO 

PORSURE: 

36 

OUTPUT 

M(X) 

37 

OUTPUT 

L(X) 


INCH:: 

X 

B 

ss: 

3 


GOTO 

BLOOP 

LOOKFIRST: 

B 

=; 

1 

BLOOP 

IPNOT 

(A=:007) 

B 

=: 

2 


GOTO 

BLOOP 

WELLMAYBE; 

B 

=: 

1 

BLOOP 

IPNOT 

(A=:377) 

B 

=: 

3 


GOTO 

BLOOP 


* INIHAL STATE IS 1 

* (lOTELESE 004/000) START ADDR 
« TURN ON A DISPLAY 

« 

* RESET THE 10 UNIT 

* "0001 01 1 1" UNIT CONTROL 
CHECK STATUS OP TAPE 

it MASK OPP RDY & RDA BITS 
it LOOP BACK UNTIL READY 

* READ THE DATA (NO EXCHANGE) 

« 

* HAVE STATE 1 DETECTED 

« 

* HAVE STATE 2 DETECTED 

* 

* HAVE STATE 3 DETECTED 

* (OOPSl SHOULDN'T GET HERE) 

it WRITE TO DISPLAY 

* LOW ORDER ADDR TO DISPLAY 

it POINT TO NEXT BYTE IN MEMORY 
it RESET STATE 3 INDICATION 
it BACK FOR MORE INDEFINITELY 

* DEFAULT STATE 1 CONTINUE 
it LOOK FOR OCTAL "007") 

it IF POUND, STATE SET TO 2 

* AND GO BACK TO FIND "377") 

* DEFAULT BACK TO STATE 1 

* LOOK FOR OCTAL "377" 

* MAIN LOAD LOOP IP FOUND NOW 

it 


Variables 

A : CPU register for I/O 
B : CPU register or mem. 

X ; Address pointer (CPU) 

ZCRO : CPU flag for zero result 

Notations 

M(X) ; memory at location in 
pointer variable X. 

Li(X) : low order 8 bytes of X 


And the equivalent 8 008 version of this algorithm.... 


Label 

8008 Code Bytes 

SIRIUS-MI 






Statement 

BOOTER: 

00 

\1I0 

a 

016 

LBI 

s 1. 


00 

M 1 1 

B 

001 

1 



00 

\112 

B 

056 

LHI 

a 2. 


00 

M13 

a 

004 

h(LOAD POINT) 



00 

M 14 

B 

066 

LLI 



00 

\115 

ss 

000 

KLOAD POINT) 



00 

\I16 

B 

006 

LAI 

a 3. 


00 

MI7 

B 

37 7 

377 



00 

M20 

B 

175 

OUT36 



00 

\121 

B 

250 

XRA 

a 4. 


00 

\122 

B 

ill 

1N4 

a 3. 

BLOOP: 

00 

\123 

B 

006 

LAI 

a 6. 


00 

\124 

m 

027 

"0001 01 11" 



00 

VI2 5 

B 

111 

1N4 

a 7. 


00 

M26 

B 

044 

NDI 

6 8. 


00 

\127 

B 

140 

"01 100 000" 



00 

\I30 

■ 

074 

CPI 

a 9. 


00 

M31 

B 

140 

"01 100 000" 



00 

M32 

m 

no 

JFZ BLOOP 



00 

M33 

m 

123 

L 



00 

\134 

B 

000 

H 



00 

M35 

B 

1 13 

INS /Read Tape) 

s 10. 


00 

\136 

B 

370 

LMA 



00 

M37 

B 

01 1 

DCB 

s 11. 


00 

M40 

B 

150 

JTZ LOOKFIRST 

s 12. 


00 

M41 

B 

166 

L 



00 

\142 

B 

000 

H 



00 

\I43 

B 

Oil 

DCB 

8 13. 


00 

\144 

B 

150 

JTZ WELLMAYBE 

a 14. 


00 

\145 

B 

202 

h 



00 

M46 

B 

000 

H 



00 

\147 

B 

Oil 

DCB 

a IS. 


00 

\150 

B 

150 

JTZ FORSURE 

a 16. 


00 

M51 

m 

154 

L 



00 

\152 

m 

000 

H 



00 

M53 

B 

37 7 

halt 

a 17. 

FORSURE: 








00 

MS4 

B 

307 

LA ^4 

a 18. 


00 

\155 

B 

175 

OUT36 



00 

M56 

B 

306 

LAL 

a 19. 


00 

\157 

B 

177 

OUT 37 



00 

M60 

B 

055 

NEXTA 

a 20. 


00 

\161 

B 

016 

LBI 

8 21. 


00 

M62 

S 

003 

3 



00 

M63 

S 

104 

JMP BLOOP . 

a 22. 


00 

\I64 

B 

123 

L 



00 

\16b 

« 

000 

H 



LAbel 8008 Code Bytes 


S1RIUS>MP 


LOOKFIRST; 


Statement 


00 \166 
00 \16V 
00 MYO 
00 M Y I 
00 M72 
00 \IV3 
00 \l7/i 
00 \175 
00 \176 
00 M77 
00 N800 
00 \20i 
WELLMAYBE: 

00 \202 
00 \203 
00 \804 
00 \805 
00 A206 
00 \207 
00 \2I0 

do \21l 
00 \2|e 
00 N213 
00 \214 
00 N215 


« 01 6 LBI 
• 001 1 

* 074 CPI 
« 00 7 7 

" 110 JFZ BLOOP 
» 123 L 
« 000 H 
“016 LBI 
“ 002 2 

* 104 IMP BLOOP 
« 123 L 

• DUO H 

“016 LBI 
« OUl 1 
« 074 CPI 

• 377 377 

« no JFZ BLOOP 
■ 123 L 
« 000 H 
« 016 LBI 
« 003 3 
» 104 JMP 
« 123 L 
000 H 


■ 23. 
a 24. 


■ 2S. 
• 26. 

a 27. 
a 28. 


a 29. 
a 30. 
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the known load point (location 2000s = intelese 004/000) as initialized at the beginning 
of the program. 


The program is a "state driven" algorithm which has 3 states of execution set by 
the content of the variable "B" (which maps into a register in the generated code for 
a microcomputer such as the 8008 code illustrated. ) The sequence of states during 
execution of the main loop "BLOOP" during normal execution is as follows: 


Start: .1111111 

Scan for "007" 

Found it, look for "377" 

Found it, transfer any further bytes to memory- 



3 3 3 3 3 3. End 


The program is set up so that if a false synchronization pattern is detected ("007" 
followed by any byte other than "377") the "WELLMAYBE" branch of the loop 
conclude s "maybe not" and goes back to scanning the input. The reason for 
scanning in this manner is to enable the program to be started via an interrupt, after 
which you can turn on the manual controls of the tape drive confident that the invalid 
data produced by the MODEM/UART combination during the leader and start up periods 
will not be falsely interpreted as good data - the specific 16-bit pattern of two bytes in¬ 
volved is not likely to occur due to random noise. 


The 8008 code corresponding to the BOOTER program's SIRIUS-MP notation is shown 
at the bottom of page 12. with symbolic notations of labels, mnemonic op codes and refer¬ 
ence numbers to the SlRlUS-MP statements in the listing at the top of the page. The 
specific hardware assumptions used for this code are documented in previous ECS 
issues and are not repeated in detail here. For this simple program, the "X" data 
quantity (a memory pointer) is translate^ ss the content of the H and L register pointer 
of the 8008. One of the restart routines defined in January ECS is utilized by the gener¬ 
ated code - "NEXTA" calculates the next address in H and L. On an 8080 this could be 
performed without a subroutine using the INX instruction with H and L, selected. On a 
6800 the corresponding fvinction would be performed using its INX instruction, with the 
variable X assumed to signify the index register "X". 


BOOTER uses output instructions directed at a binary display to illustrate the prog¬ 
ress of the program. At initialization, the display left half (OUT36) is loaded with 8 
"on" bits. (SIRIUS statement 3). Then, following the synchronization detection, the 
d 2 da transfer branch FORSURE displays the current byte at left (OUT36, statement 18) 
and the current low order address at right (OUT37 generated by statement 19). 

The small loop from statements 6 to 9 is used to cause the program to wait \mtil the 
flags of the UAR/T subsystem (see article ECS-6 and January 1975 ECS) indicate that 
a character has been received. The tape unit control code "027g" defined at statement 
6 is used to signify the data rate ("0001" for 1210 baud), channel ("01") and . selection 
for input (the last two bits. ) ^ 

If you use BOOTER to load IMP from one of the cassettes supplied by M. I*. Publish¬ 
ing Co. ($7. 50 each post paid) you will have to additionally load by hand the content of the 
other restart instructions routines before changing the interrupt branch to point to the IMF 
entry point at location 013/000 (Intelese. ) 
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IMP EXTENSIONS FOR TAPE INTERFACE CONTROL (Continued.. . ) 


In the March issue of ECS, I started a presentation of 
extensions to the Interactive Manipulator Program for tape 
block write, compare and read operations. This article 
contains the remainder of the listings. With the exception 
of the three routines on this page, the additional 8008 code 
is given in its SIRIUS-MP form and in absolute octal with 
mnemonics decoded. 


One aspect of the SIRIUS-MP language which I have not dealt with explicitly in this 
issue's discussion is that of argximent/parameter linkage for subroutine calls. Because 


a machine-dependent argument/parameter linkage is used for the 8008 versions of the 
three routines on this page, I present them here in the same commented listing form used 


for previous issues of ECS. The 
routines are utility functions for the 
two-byte increment/decrement func¬ 
tions and comparison. The parameter 
linkages to these routines are formed 
by passing symbols (see Feb. '75 ECS) 
in registers for lookup. 

D2B is the two byte decrement 
operation, which is entered with the 


012M38 « 075 SYM 
OI2M33 « 060 INL 
0I8M34 ■ 307 LAM 
0I2\)33 • 024 SUl 
0I2M36 • 001 1 
012M37 • 370 LMA 
012M40 - 003 RFC 
012M41 « 061 DCL 
012\142 " 30 7 LAM 
012\143 « 024 SUl 
0I2V144 ° 001 1 
012\146 = 370 LMA 
012\146 = 007 RET 


Go pick up argument address 

Point ahead (assume not at page bound) 

Fetch the low order byte. 

Subtract 1 - decrement will not do! 
Save result 

Return on no borrow condition. 

Point to high order byte 
Fetch it 

Also decrement with subtract 

so that borrow (C) may be set. .. 
Save result 

With carry indicating net underflow, 


symbol of the operand contained in 


the 8008's A-register. The operand 


is decremented by subtraction due i 2 B: 
to the properties of a zero underflow 
(the Zero flag detects this state one 
number too early at 0, not -1. ) On 
return, the carry flag indicates a 
16-bit underflow if any 

I2B is the corresponding two byte 
increment operation, which is also 
entered with the symbol of the oper¬ 
and in the 8008's A register. The 
8008's increment instructions are 
used, since the zero state is a reli¬ 
able overflow indicator. On return, 
the zero flag indicates a 16-bit over¬ 
flow if any. 

C2B is a two byte comparison op¬ 
eration, with a more complicated link¬ 
age. The‘two operands are passed as 
symbols in the B and C registers. The 
result is passed back as the content of 
the "E" register : 1 if not equal, 2 if 
equal. This can be tested by a decrement 
instruction followed by a jump on zero . 


Routine t'o increment two bytes - 


011\313 


0?b 

SYM 

011N314 

« 

060 

INL 

OllNSlb 


317 

LBM 

0tl\316 

m 

010 

INB 

011\317 

■ 

371 

LMB 

0U\320 

e 

013 

RFZ 

011^321 

« 

061 

DCL 

011N322 

X 

317 

LBM 

011\323 

X 

010 

INB 

01IN324 


371 

LMB 

011\325 


00 7 

RET 


enter with symbol parameter in A 
l^ok up the parameter address 
Point to, 

load from memory, 
increment and 

save the low order byte. 
Return direct if no overflow 
Point to, 

load from memory, 
increment, 

and save the high order byte. 
Then return always. 


Routine to compare bytes - in two’s. 


010\234 

= 

046 

LEI 

O'l0\23b 

X 

001 

1 

010\236 

n 

301 

LAB 

010\237 

m 

075 

SYM 

010\240 

m 

337 

LDM 

010\241 

u 

302 

LAC 

010N242 

m 

075 

SYM 

010\243 

m 

303 

lAD 

010X244 

» 

277 

CPM 

010X246 

= 

013 

RFZ 

010X246 

= 

055 

NEXTA 

010X247 

m 

337 

LDM 

010X250 

u 

301 

LAB 

010X251 

s 

0 75 

SYM 

010X252 

= 

055 

NEXTA 

010X253 

= 

303 

LAD 

010X254 


277 

CPM 

010X255 


013 

RFZ 

010X256 

X 

046 

LEI 

010X257 

= 

002 

2 

010X260 

0 

00 7 

RET 


Enter with symbol parameters in 
registers B and C. 

Return default 1 (not equal. ) 

Fetch first parameter address 
and fetch the parameter. 

Fetch second parameter address 
and compare against 

first parameter value... 

Return (E= 1) if unequal. 

Point to next address of second parm. 
Fetch second parm second byte 

Point to first parm again 
look NEXTA him too! !! 

Compare first parm, second byte 
And again return (E = l) if unequal. 
Otherwise both bytes of both 
two sets are equal and can 
return with equality result. 
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The notational power of a more abstract method of programming is illustrated by com 
paring the expression of the new IMP extension segments on page 16 with the correspon¬ 
ding "generated code" for the 8008 printed later. The routines listed in SIRIUS-MP 
form for the tape extension begin with the main portion of the program. .. 

READ/COMPARE main routineisat the left hand side of page 16 held sideways. This 
33-statement SIRIUS - MP program is inwjked when the IMP command decoder detects a 
"shift R" for read or "shift C" for compare. The difference in the two routines is deter¬ 
mined by the entry point - line 1 for READ, line 28 for COMPARE. The logic at the 
entry points sets up a jump address in the "GPJMP" indirect branch location (this over¬ 
writes the previous use of GPJMP to get to READ or COMPARE from IMP. ) This 
switch (the choice of branch paths) is required so that the same general control flow can 
be use for both the READ and COMPARE operations - the difference being in what is 
done with the information read from tape. The switch point in the flow occurs at state¬ 
ment 14, and can be illustrated in 
flow chart terms by the diagram at 

the right. 111.11^S COMfl^RC: 

The common portion of the pro¬ 
gram provides the overall structure 
of a read operations initialize the 
UAR/T, read a dummy character 
at the first RDA time, read the 
two length code bytes written by 
the OUTCNT routine (see below) when 
the tape is prepared, then enter a 
loop which continues until the data 
count is exhausted. 

When the READl branch of the 
flow is taken during a read opera¬ 
tion, the current memory location 
pointed to by IBUFF receives the 
input character found in a variable 
called "B" (a CPU register for the 
8008 version of the program. ) 

When the COMPl branch of the 
flow is taken during a compare oper¬ 
ation, the current byte pointed to by 
IBUFF is compared to the input 
byte in the variable "B" - and an 
error count is incremented in the 
variable "BADDATA" (16 bits worth) 
to keep a tally of the badnesses. 

The data count is kept in the var¬ 
iable "ICNT" Which starts out at -1 
and is counted up until it equals the 
block count stored in !'NCNT" after 
it is read from the tape. The test for 

end of transfer is found at statement 
20, a SIRIUS "IFNOT" operation. 



MYWAVT - AETUftM 








H 

n 

w 



READ; 





INPUT2; 


1 

TCGPJMP) 

; 

W(READl) 

^ SET READ JUMP SWITCH 

1 

A 

sr; 


RC: 




2 

A 

lOEXCH 

2 

TAPECTRL 

OR: 

"0000 00 

1 1" * FORCE INPUT SELECT 

3 

B 

=; 

3 


CLEAR 

A 


4 

A 

AND; 

k 

A 

lOEXCH 

4 

* RESET THE 10 UNIT 

5 

INPUT2 

IFNOT 


INITIALIZE; 




6 

A 

=; 

5 

k 

OUTPUT 

TAPECTRL 

SET SELECTED CONTROL STUFF 

7 

A 

AND: 

6 

I BUFF 

=;; 

MEMADDU 

* START INPUT AT MEMADDR 

8 

INPUTIT 

IP 

7 

IGNT 

. 

-1 

* INITIAL COUNT TO MATCH OUTPUT 

9 


INCR:: 


DUMMYIN: 





INPUTIT: 


8 


CALL 

INPUT2 

GO FETCH BYTE (WAIT LOOP) 

10 

A 

INPUT 


HIGin.NGTH; 




11 

B 

=: 

9 


CAI.L 

INPUT2 

* GET HIGH ORDER LENGTH 

12 


RETURN 

10 

NCNT 

=: 

B 

SAVE B INPUT IN NCNT H.O. 





LOWLNGTH; 







11 


GALL 

INPUT2 

* GET LOW ORDER LENGTH 




12 

NCNT(l) 


B 

* STORE AT NCNT+1 





FORALL; 





NEWOUTCNT: 


13 


CALL 

INPUT2 

NORMAL DATA BYTE FETCH 

1 

B 

=: . 

li; 


GOTO 

GPJMP 

* SELECT COMPARE OR READ VIA 

2 


CALL 





* VARIABLE JUMP TARGET 

3 

A 



READl: 




4 

B 

=; 

15 

M(IBUFP) 

=: 

B 

* IP READ THEN STORE IT 

5 

5 

OUTPUT 


GOTCHA; 




6 


CALL 

16 

37 

OUTPUT 

B 

^ DISPLAY INPUT DATA 

7 

A 

=; 

n 

36 

OUTPUT 

0 

* CLEAR OTHER DISPLAY TO ZERO 

8 

C 

=: 

18 


INCH:: 

I BUFF 

* POINT TO NEXT INPUT ADDRESS 

9 

5 

OUTPUT 

19 


INCR;; 

ICNT 

* INCREMENT WORKING COUNT 

10 


GALL 

20 

FORALL 

IFNOT 

(ICNT=::NCNT) -5^ TEST END OF BLOCK 

11 


RETURN 


ENDALL: 







21 


CALL 

INPUT2 

READ PINAL LENGTH BYTE 




22 

36 

OUTPUT 

B 

# AND DISPLAY 




23 


GALL 

INPUT2 

* READ SECOND FINAL LENGTH BYTE 


ONOPP: 


2k 

37 

OUTPUT ■ 

B 

* AND DISPLAY IT TOO 

1 

A 

=; 

25 

TAPECTRL 

AND; 

"1111 11 

0 0" * TURN OFF INPUT SELECT 

2 

A 

AND: 

26 

k 

OUTPUT 

TAPECTRL 

* TURN OFF THE DRIVE... PATCH 

3 

TON 

IF 





* IN A 2 SECOIH) WAIT HERE 


TOFF: 






* IP NEEDED - SEE TEXT ... 

4 

B 

=: 

27 


KBYWAIT 


* SLEEP PERCHANCE TO DREAM 

5 


GOTO 


COMPARE; 





TON; 


28 

T(GPJMP) 

=:: 

WfCOMPl) 

SET COMPARE JUMP SWITCH 

6 

B 

=: 

29 

BADDATA 

=;; 

0 

* ZERO OUT BAD DATA...COUNT 


EITHER: 


30 


GOTO 

RC 

« ENTER NORMAL FLOW 

7 

A 

=• 


COMPl: 




8 

A 

AND: 

31 

GOTCHA 

IF 

(M(IBUFP)=;B) ^ TEST TAPE AGAINST MEMORY 

9 

A 

OR: 

32 


INCR:: 

BADDATA 

MISSED SOME BITSH! 

10 

TAPECTRL 

= ! 

33 


GOTO 

GOTCHA 

* BACK FOR MORE... 

11 

4 

OUTPUT 


12 KEYWAIT 


TArECTRL » FETCH 10 CONTROL WORD 
k EXCHANGE FOR STATUS 

A SAVE STATUS IN B 

"01 100 000" * MASK DESIRED BITS 

(A=;"01 100 000") ^ WAIT TILL READY 

B RESTORE STATUS PROM B 

"00 000 111" MASK ERROR BITS 
(A=;"00 000 111") -:r INVERTED NO ERRORS 

BADFORM INCREMENT’ DATA FORMAT ERRORS 


5 « READ THE LATESTCHARACTER 

A * PASS BACK VIA B REGISTER 

« BACK TO CALLER 


i5io 


MAKE IT 1.5 SEC DELAY 

WAITCS 


VIA CENTISECOND DELAYER 

COUNT 


SEND OUT THE FIRST 

A 

* 

COUNT BYTE 

A 


AND SAVE IN 3 

WAITOUT 


WAIT UNTIL NOT BUSY 

COUNT(l) 

* 

GET SECOND BYTE AT COUNT+1 

A 


SAVE IT IN C 

A 

* 

AND OUTPUT TO TAPE 

WAITOUT 

» 

WAIT UNTIL NOT BUSY 


% 

THEN BACK 

TAPECTRL 


FETCH OLD TAPE CONTROL 

"00 000 i 

010" w CHECK OLD STATE OP SELECT 

ZERO 

* 

CHANGE TO ON IP OFF 

2 

« 

CHANGE TO OFF IP ON 

EITHER 


THEN DO THE CHANGE 

0 

* 

CHANGE TO ON IP OFF 

TAPECTRL 


FETCH OLD CONTROL AGAIN 

374 

* 

MASK AND SAVE HIGH ORDER 6 BITS 

B 


COMBINE WITH NEW CONTROL 

A 


SAVE NEW CONTROL 

A 


TURN TAPE MOTOR OFF OR ON 



BACK TO SLEEP YOU IMP!11J 


Note: Reference numbers to SIRIUS statements are Notations: T(GPJMP) 
provided at the local level for each block of functional *^(READ1) 

code illustrated here. They correlate to the 8008 examples NAME{n) 

of executable machine codes> within each block. 



; address part of jump 
mem. address of RE ADI 


.th 


byte of NAME 





O 

en 


IMP program tape extensions expressed in a SIRIUS fashion. 
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Label 

8008 Code Bytes 


SIRIUS-MP 






Statement 

R£AD: 





1 


004\0U0 


006 

LAI 

• 1. 


004V001 


010 

s(GPJMPAL) 



004\002 


U7d 

SYM 



004\U03 


076 

LMl 



0Q4N004 


107 

L(R£AD1) 



004\00b 


060 

INL 



004N006 


076 

LMl 



0U4N00Y 


004 

H(READl) 


RC: 







004\U10 


006 

LAI 

• Z. 


004\U11 


014 

• (TAPECTRL) 



004NO12 


075 

SYM 



004NO 13 


307 

LAM 



004N014 


064 

ORl 



004NOlb 


003 

••OOOOOOll" 



004NO16 


370 

LMA 



004N017 


250 

XRA 

• 3. 


004NO20 


111 

1N4 

• 4. 

INITIALIZE 

; 






004N021 


006 

LAI 

• 5- 


004N022 


014 

• (TAPECTRL) 



004N023 


0/5 

SYM 



004N024 


307 

LAM 



004N025 


111 

1N4 



004N026 


006 

LAI 

• 6. 


004N027 


006 

s(MEMADIXl) 



004NO30 


075 

SYM 



004NO31 


317 

l^M 



004N032 


060 

INL 



004NO33 


327 

LCM 



004NO34 


006 

LAI 



004N03b 


020 

s(lBUFF) 



004^036 


075 

SYM 



004NOi7 


371 

LMB 



004N040 


060 

INL 



004N041 


372 

LMC 



004N042 


006 

LAI 

■ 7. 


004N043 


016 

■aCNT) 



004N044 


075 

SYM 



004N04S 


006 

LAI 



004N046 


377 

"lullin'' 



004N047 


370 

LMA 



004N0t>0 


060 

INL 



004NO51 


370 

LMA 


DUMMYIN: 







004N052 


106 

CAL INPUT2 

• 8. 


004NO53 


001 

L 



004NO54 


012 

H 


HIGHLNGTH: 






004N055 


106 

CALINPUT2 

• 9. 


004NO56 


061 

L 



004N0b7 


012 

H 



004NO60 


000 

LAI 

• 10. 


004N061 


022 

• (NCNT) 



004N062 


075 

SYM 



004NO63 


371 

LMB 


LOWLNGTH 

. 






b04N064 


106 

CAL INPUT2 

• 11. 


004NO65 


061 

L 



004NO66 


012 

H 



004N067 


006 

LAI 

• 12. 


004NO70 


022 

• (NCNT) 



004NO71 


0/5 

SYM 



004NO72 


055 

NEXTA 



004NO73 


371 

LMB 


FORALL: 







004NO74 


106 

CALL INPUT2 

• 13. 


004NO75 


061 

L 



004NO76 


012 

H 



004NO77 


006 

LAI ^ 

Globally 


004N100 


020 

• (IBUFF) > 

k optimised: codt 


004N101 


100 

CALL MEMSYM 

1 moved ahead 


004N102 


002 

L 

of the GPJMP 


004N103 


012 

H 



004N104 

a 

104 

JMP GPJMP 

• 14. 


004N105 


015 

L 



004N106 


000 

H 



Label 

8008 Code Bytes 

SIRIUS-MP 






Stat^ent 

RE ADI: 

004N107 

K 

371 

LMB 

• IS. 

GOTCHA: 

004NI10 


301 

LAB 

• 16. 


004NI11 


177 

OUT37 



004N1I2 


250 

XRA 

• 17. 


004NI13 


175 

OUT36 



004N114 


006 

LAI 

• 18. 


004N115' 


020 

• OBUFF) 



004N1I6 


106 

CAL IZB 



004N117 


313 

L 



004Nie0 


Oil 

H 

• 19. 


004N181 


006 

LAI 


004N122 


016 

s(lCNT) 



004N123 


106 

CAL IZB 



004N124 


313 

L 



004N12S 


Oil 

H 



004N126 


016 

LBI 

• ZO. 


004 N12/ 


016 

• aCNT) 



004NI30 


026 

LCl 



004N131 


022 

• (NCNT) 



004N132 


106 

CAL CZB 



004N133 


234 

L 



004N134 


010 

H 



004\I35 


041 

DCE 



004NI36 


150 

JTZ FORALL 



004\I37 


074 

L 



0Q4NI40 


004 

H 


ENPALL: 

004N141 


106 

CALL INPUTZ 

• Zl. 


004N142 


061 

L 



004NI43 


012 

H 



004NI44 


301 

LAB 

• ZZ. 


004\14S 


175 

OUT36 



004X146 


106 

CALL INPUTZ 

• 23. 


004N147 


061 

L 



004NI50 


012 

H 



004M51 


301 

LAB 

• 24. 


004X152 


177 

OUT37 



004X153 


006 

LAI 

• 25. 


004X154. 


014 

• (TAPECTRL) 



004M5S 


075 

SYM 



004X156 


307 

LAM 



004X157 


044 

NDl 



004X160 


374 

"U lU 100" 



004X161 


370 

LMA 



004X162 


111 

1N4 

■ 26. 


004X163 


025 

KEYWAIT 

• Z7. 

COMPARE: 

004X164 


006 

LAI 

• 28. 


004X165 


010 

• (CPJMPAL) 



004X166 


075 

SYM 



004X167 


076 

LMl 



004X170 

004X171 


206 

060 




004X172 


076 

LMl 



004X173 


004 

H(COMPl) 



004X174 


006 

LAI 

• 29. 


004X175 


024 

• (BAODATA) 



004X176 


075 

SYM 



004X177 


250 

XRA 



004X200 


370 

LMA 



004X201 


060 

INL 



004X202 


370 

LMA 



004X203 


104 

JMP RC 

• 30. 


004X204 


010 

L 



004X205_ 


004 

H 


COMPl: 







004X206 


301 

LAB 

• 31. 


004X207 


277 

CPM 



004X210 


150 

JTZ GOTCHA 



004X211 


110 

L 



004X212 


004 

H 



004N213 


006 

LAI 

• 32. 


004X214 


024 

• (BADDATA) 



004X215 


106 

CAL IZB 



004X216 


313 

L 



004X217 


Oil 

H 



004X220 


104 

JMP GOTCHA 

• 33. 


004X221 


110 

L 



0U4N222 


004 

H 
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8008 Generated Code for MISCELLANEOUS routines (p 16, righ<) 


L.abel 

8008 Code Dyles 


SIRIUS-MP 

Label 

8006 Code Bytes 

SIRIUS - MP 






Statement 





Statement 





• 

# 

ONOFF; 




# 

INPUT2: 







011X264 

n 

006 LAI 

e 1. 


012\061 

* 

006 

LAI 

8 1. 


011X265 

m 

014 8(TAPECTRL) 



012\062 

u 

014 

s(TAPECTRL) 



011X266 

K 

075 SYM 



012\063 

K 

0 75 

SYM 



011X267 

m 

30 7 LAM 



012X064 

B 

307 

LAM 



011X270 

m 

044 NOI 

8 2. 


012X065 

B 

1 1 1 

IN4 

8 2. 


011X271 

a 

002 "00 000 010" 



012Xp66 

» 

310 

LBA 

6 3. 


011X272 

a 

150 JTZ ton 

8 3. 


012X067 

B 

044 

NDl 

8 4. 


011X273 

a 

302 L 



012X070 

B 

140 

"01 100 000" 



011X274 

a 

OllH 



012X071 

B 

074 

CPI 

s 5. 

TOFF: 






012X072 

B 

140 

"01 100 000" 



011X275 

a 

016 LBI 

8 4. 


012X073 

B 

110 

JTZ INPUT2 



011X276 

a 

000 0 



012X07^4 

S 

061 

L 



011X277 

a 

104 JMP EITHER 

8 5. 


012X075 

E 

012 

H 



011X300 

a 

304 L 



012X0 76 

B 

301 

LAB 

8 6. 


011X301 

a 

Oil H 



012X077 

S 

044 

NDI 

8 7. 

TON; 






012X1UU 

S 

00 7 

"00 poo 111" 



OilX302 

a 

016 LBI 

8 6. 


012X101 

E 

074 

CPI 

6 8. 


011X303 

a 

002 2 



012X102 

« 

00 7 

"00 000 111" 


EITHER: 






012X103 

B 

150 

JTZ INPUTIT 



011X304 

a 

30 7 lam 

8 7. 


012X104 

e 

113 

L 



011X305 

8 

044 NDI 

8 8. 


012X105 

B 

012 

H 



011X306 

a 

374 "11 111 100" 



012X106 

B 

006 

LAI 

8 9. 


011X307 

a 

261 ORB "xxxxxxBo" a 9. 


012X107 

s 

026 

s (BADFORM)! 



011X310 

a 

3 70 LMA 

8 10. 


012X1 10 

B 

106 

CALL I2B 



U 11 X31 1 

a 

111 IN4 

8 U. 


012X1 1 1 

e 

365 

L 



011X312 

ss 

025 KEYWAIT 



012X112 

B 

010 

H 







INPUTIT: 

012X113 

s 

113 

INS 

6 10. 







012X114 

B 

310 

LBA 

6 U. 







012X11 5 

» 

00 7 

RETURN 








OUTCOUNT: 


012X200 

a 

104 

JMP NEWOUTCNT 

Here 

012X201 

a 

116 

L 

new ver 

012X202 

a 

010 

H 


T: 




a 1. 

010X1 16 

'a 

016 

LBI 

010X117 

a 

017 

15io 


010X120 

a 

106 

CALL WAITCS 

8 2. 

010X121 

a 

1 16 

L 


010X122 

a 

012 

H 


010X123 

a 

006 

LAI 

s 3. 

010X124 

a 

022 

s (COUNT) 


010X125 

a 

075 

SYM 


010X126 

a 

30 7 

LAM 


010X127 

a 

310 

LBA 

8 4. 

010X130 

a 

113 

INS 

8 5. 

010X131 

a 

106 

CAL W.UTOUT 

s 6. 

010X132 

c 

147 

L 


010X133 

= 

012 

H 


010X134 

a 

006 

LAI 

8 7. 

010x135 

a 

022 

8 (COUNT) 


010X136 

a 

0/5 

SYM 

6 

010X13/ 

a 

060 

INL 


010X140 

a 

30 7 

LAM 

6 8. 

010X141 

a 

320 

LCA 

010X142 

a 

113 

INS 

8 9. 

010X143 

a 

106 

CALL WAITOUT 

8 11. 

010X1 44 

c 

14 / 

L 


010X145 

a 

012 

H 


010X146 

a 

007 

RETURN 

s 12. 


■ OUTCOUNT. 


Patches to Previous Code 


Tape Extension 
VARIAB LES 
(in order of appearance) 

GPJMP, symbol 10 
TAPECTRL, symbol 14 

A, CPU register 

MEMADDR, symbol 06, input 
to tape transfers. 

IBUFF, symbol 020 

ICNT, symbol 016 
NCNT, symbol 022 

B, CPU register 
BADDATA, symbol 24 
BADFORM, symbol 26 


TAPECMDS: 







012X352 

a 

31 7 

"O" 




018X353 

a 

321 

L(JONOFF) 



012X2/2 

B 

012 

"34" 

is TAPECMDS (new value) 

J ONOFF: 

012X273 


352 


JMP entry to the 


012X321 

a 

IU4 

JMP 

ONOFF 


012X322 

= 

264 

L 


ONOI F routine sand¬ 


012X323 

a 

01 1 

H 


wiched in spare bytes. 

READJ: 

013X313 

a 

104 

JMP 

READ 

New IMP READ 


013X314 

a 

000 

L 


entry address in 


013X315 

a 

004 

H 


thi 6 jump. 

COMPJ; 

013X316 

s 

1U4 

JMP COMPARE New IMP COMPARE 


013X317 

X 

164 

L 


routine entry address 


013X320 

a 

004 

H 


now in this jump. 


COUNT, symbol 22 

ZERO, CPU flag 

Note: NCNT, COUNT are 
equivalent; ICNT and 
TCOUNT (see March ECS) 
are equivalent. 




ECS Volume 1 No. 4 


19 


April 1975 


The INPUT2 subroutine is at the top right hand side of page 16 held sideways. This 
12-statement SIRIUS-MP subprogram is invoked by a subroutine CALL whenever another 
program wants to "read" a byte from the tape unit according to the content of TAPECTRL. 
The reading method incorporated in the software of IMP to date is a "polling" technique 
in which a loop tests status bits of the I/O device (UAR/T "RDA" and a motor turn-on 
oneshot "ready" signal. ) The loop consists of SIRIUS-MP statements 1 to 5 of INPUT2. 
The routine breaks out of the loop, reads the data and returns with the data byte in the 
variable "B" (a register in the 8008 generated code). The three UAR/T reception 
status bits (parity error/frauning error/overrun error) are checked and an error count 
in BADFORM is incremented if no errors are detected. 

The OUTCOUNT routine of the March issue of ECS was modified to improve performau 
in the course of rewriting the comparison software in SIRIUS for this issue. The prob¬ 
lem with the original version was the fact that an e 3 q>licit output wait is required for 
reliable reading of the data . Thus a patch is placed at location 012/200 to jump to the 
new version of the program, loaded in some spare memory address space at 010/116. 

The NEWOUTCNT has two changes: a) I increased the time delay before output to 
1. 5 seconds (SIRIUS statements 1 and 2 ); b) I have inserted calls to WAITOUT after 
each output of a byte (SIRIUS statements 5 zuid 9 of NEWOUTCNT. ) 

The ONOFF routine is a new routine added to support a new tape control command, 
"TO" entered from the keyboard device. The idea here is to have a way to turn on the 
motor for purposes of listening to data with the ear, for rewinds of long duration, or 
for recording non-digital comments with the cassette recorder's built-in microphone. 

The ONOFF routine itself is very simple, comprising a set of 12 SIRIUS statements 
which map into 23 8008 bytes in the sample generated code. The "TO" function comple¬ 
ments the current state of the motor control bit in TAPECTRL and outputs the result to 
currently selected tape drive via the "IN4" instruction connected to the tape controller. 

In setting up to run IMP with the new extensions, the patches to TAPECMDS, JONOFF, 
and READJ/COMPJ locations of IMP must be made as indicated in the detail listing 
of page 18. The TAPECMDS table is extended for the new "O" subcommand by starting 
it one byte earlier; the symbol table symbol "34" for TAPECMDS is adjusted to reflect 
this addition. The new execution jump JONOFF is added to get the program into the 
ONOFF routine, and the READJ/COMPJ jumps are changed to reflect altered placement 
of these routines from the original layout. One other change is required to the symbol 
table published previously: the address of symbol "20" should be changed to "220" in 
byte 012/301 of the 8008 code. This symbol has been chcinged from its original use 
and now becomes the memory pointer "IBUFF" with two bytes instead of the original 
1 byte of reserved space. 


COMMENTS ON THE ECS-8 DESIGN: 

The output of the TSI (serial data to the computer interface) line is not suitable for 
an interrupt driven UAR/T software interface without use of some masking logic. The 
problem is this: the FSK input decode is done by the phase lock loop of the XR-210. 
When null inputs (eg: tape leader period, or any time without a mark signal) occur, the 
phase lock loop hunts around for a lock - thus causing the comparator to have its input 
switch back and forth with the result being a digital noise signal on the TSI line. If 
the UART is listening, it will decode erroneous characters in this mode. The software 
of this article ignores the problem by not listening unless good data is coming. 
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Notes on NAVIGATION IN THE VICINITY OF OC- AQUILA. .. #1 


This article begins a regular series of information and 
commentary on the use of the Intel 8080 in an ECS context, 
with occasional specific reference to packaged systems such 
as the MITS Altair product. In addition to the MITS product, 
there is at least one other source of the 8080 chips and boards 
advertising in the pages of Radio Electronics/Popular Elec¬ 
tronics. This first installment concerns some general com¬ 
ments on the 8080 instruction set and specific suggestions con- 
* cerning 16-bit arithmetic operations (addition/subtraction) in 
applications other than address calculations. 


AO-1.1: Addressing Modes. 

One of the most basic questions to be asked whenever you ponder the use of a new 
computer instruction architecture is "what are its addressing modes?" The answers all 
lie in the hardware designer's backyard whenever a specific existing machine such as the 
8080 is considered. How do I get at the data in memory when I want to perform some oper¬ 
ation in the machine? Are there different ways of reaching the same data item? And so 
on. The effects of addressing and data reference will color the whole process of gen¬ 
erating programs for the architecture of the machine in question. For instance, if the 
machine is a "stack machine" (not a machine with a stack, but one designed for opera¬ 
tions between stack elements) then the addressing can almost exclusively be implied by 
the way operations are done. On such a machine, the only bits needed for an instruction 
are the data bits which specify an operation. But in the real world of existing and 
implemented machines available to the ECS type of application, the coloring of coding is 
much more conventional - addressing is performed as part of the instruction or as 
part of an implied setup in a CPU register under program control. In the Intel 8080 
(as in the 8008) the design of addressing modes is a fairly arbitrary pot-pouri of methods 
fraught with special cases not ammenable to concise siimmary without losing information. 

In order to write programs these addressing modes must be known and understood so that 
the best of alternatives (if any) can be evaluated and used in a given programming situa¬ 
tion. In the comments below, a few of the conventional addressing concepts in 
computer designs are isolated and illustrated with regard to the 8080 . 

AO-1.2: Immediate Addressing. 

Immediate data addressing exists in some form in most contemporary computers, 
with the usual definition being a constant bit pattern of one word length, following the 
operation code in a program. The 8080 includes this form of addressing with all the 
immediate operations which exist on its antecedent the 8008, plus some extensions which 
make the architecture more useful as a general purpose computing element. The primary 
extension of immediate addressing is to the inclusion of a long (16-bit) form of the con¬ 
cept in certain limited classes of move (load/store) operations with respect to GPU reg¬ 
isters. The 8080 partitions 6 of the 7 CPU registrsinto three pairs "index register 
which may be loaded with l6-bit numbers using immediate addressing. The primary in 
tention of such operations is the loading of an address, but programmers can and 
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do use operations for whatever purpose is required to solve a problem - so whenever 
one needs a 16-bit "literal" data item this form of double byte immediate operation can 
be used to load CPU registers. 


One particular use of the two-word immediate form in its intended application is 
the initialization of the stack pointer as a part of setting up execution of a prog¬ 
ram. In large scale systems the equivalent of a stack pointer (ie; system defined 
addressing parameters) is usually determined by the "operating system" prior to 
the call which invokes a user-program. But in your use of a microcomputer of 
the 8080 (or Motorola 6800) design, with minimal software, you can make no as¬ 
sumptions about the initialization. To be used, the stack must exist in random 
access read/write memory so that the temporary linkage data associated with 
the CALiLi operation and its arguments can be stored. In order for this linkage 
to occur, the stack pointer (SP) must point to the RAM area. One way to initial¬ 
ize the stack pointer following the start of execution is contained in the following 
SIRIUS-MP notation and its 8080 translation: 

SIRIUS: 8080: 

SP -:: location LXI SP, location 

In both instances, the "location" is the 16-bit integer number which is the address 
of the stack area. 


AO-1. 3: Absolute Addressing. 

The design of a computer instruction set involves many trade-offs, the evaluation of 
options with inputs ranging from the preferences of programming individuals to the phys¬ 
ical constraints of the LSI chip. In the best of all possible programming worlds, one 
would like to see a consistent set of addressing modes applicable in principle to any of the 
basic operations possible. In particular, a more extended use of an absolute (in-instruc- 
tion stream) form would be desirable than has been implemented with the 8080. There 
are two basic operations available in the 8080 instruction set which reference memory 
from within the instruction stream. These are the load (LDA, LHLD) and store (STA, 
SHLD) operations in 8 and 16 bit variations. For program code which involves fixed 
data areas at locations allocated by hand or by an assembler/compiler, these operations 
will be used extensively to prepare data for the execution of actual "work" -since the 
actual work cannot reference memory directly. The use of load and store for this pur¬ 
pose is highly conventional in many minicomputers, although usually at least one of the 
algebraic/logic operation operands can be acquired by a direct or indirect memory ref¬ 
erence in the instruction stream. (As a point of contrast, the Motorola 6800 microcom¬ 
puter can perform most of its arithmetic/logical operations with one in-instruction addrese 
reference to memory. ) 

AQ-1. 4: Pointer Addressing. 


One area where the 8080 has some excellence is in the number of CPU registers it 
has and the fact that three different pairs can be used as "index registers" for fetching 
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data to an accumulator (all pairs) or referencing memory operands (H/L only) of the 
arithmetic operations. It is thus fairly easy to keep pointers around locally in the 
CPU without the need to transfer them to another location when making a reference 
based upon the index. The pointers are, however, only good for one operation in 
general - referencing data in load/store situations, and thus not as useful 

as they might otherwise have been. The memory reference modes of all the 8-bit 
arithmetic and logical instructions use one of these pointers, the H/L register pair, 
to address the one memory operand (the implied second operand is the acctimulator* 
register A. ) All the procedures and tricks applicable to setting up H/L pointer addresses 
in the earlier 8008 microcomputer design apply as well to the equivalent H/L forms of 
the 8080. 

* 


One particular programming trick which will prove useful in manipulating blocks 
of data involves the use of one pointer pair - D/E - to point to one operand block 
and a second pointer pair - H/L to reference the second block. Suppose the 
problem is to "AND" all the bytes of one block with the bytes of another and to 
store the result in the second. The basic set of instructions used to set up the 
loop would be: 

LXI D address 1 

LXIH address 2 set up addresses 

With this setup, the heart of a loop to transfer the data with an AND condition as 
required by the problem statement would be: 


MOV, A,M 
XCHG 

ANA M 
MOV M,A 
INXH 
XCHG 
INXH 


Fetch first operand byte 
Establish second operand address, but 
save first operand address 
AND with second byte 
Save in second operand byte 
Increment address 
Move back in exchange 
Increment address 


This code does not include the instructions needed to establish a loop - to tranS' 
fer a block with this operation would require a loop count and loop count decre¬ 
ment followed by conditional test for continuation. 


This same general scheme of switching the D/E with H/L registers can be used 
quite widely your program must step simultaneously through two regions of mem¬ 
ory. The technique only works with D/E & H/L unless you want to take a calcu¬ 
lated risk and exchange with the stack pointer instead of D/E. 


AQ-1. 5: 16-Bit Operations & 16-Bit Addition/Subtraction. 

The 8080 has a specific and limited set of 16-bit operations which can be used to some 
advantage both for the intended purpose (address calculation and setup) and in more gen¬ 
eral problems. The l6-bit operations are . . . 

l6-bit Load and Store between register pairs and memory or immediate 
(Load only) data. 

l6-bit Addition intended for address calculation. 

l6-bit Increment/Decrement useful in loop counting & address changing. 
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For the more general usage of the 16-bit addition operation in programs requiring 
the extended precision addition / subtraction, the H/L register pair can be treated as 
if it were a 16-bit accumulator for the purposes of calculation with the actual results 
being stored ultimately in memory operands. The boxes below illustrate two calculations 
in 16 bit precision, under the following assvimptions: 

a. Variable P is a two-byte operand at locations P and P + 1. 

b. Variable Q is a two-byte operand at locations O and Q -f 1. 

c. The content of A, H and L registers is irrelevant prior to and 

following the calculation. 

d. Absolute addressing will be used with the result stored back in P, as if 

P were a "software accumulator. " 

Note the differences in the size of the little routines involved - for the addition case, 
the setup and execution is fairly compact. For subtraction the need to form the two's 
complement negative of the Q operand complicates the picture... 


The SIRIUS-MP statement: P 4 :: Q * 16-BIT ADD 

generates. .. 

LHLD 

Q Get first operand bytes to O 

XCHG 

Move first op to D/E 

LHLD 

P Get second operand (soft, accum. ) 

DADD 

Add 0 to P giving P 

SHLD 

P Store result back into new P value 


The SIRIUS-MP statement: 

P -:: 0 * 16-BIT SUBTRACT 

generates. .. 



LDA 

Q 

Get first byte, negative operand. 

CMA 


Complement it 

MOV 

D, A 

Move it to D of D/E pair. 

LDA 

0+1 

Get second byte, negative operand. 

CMA 


Complement it. 

MOV 

E, A 

Move it to E of D/E pair. 

INX 

D 

Increment complement giving -Q value 

LHLD 

P 

Get software accumulator value 

DADD 


Value of P - Q now in H/L 

SHLD 

P 

Save back in software accumulator. 


After either of these operations, the carry flag can be tested to find out if an overflow 
occurred, thus in principal allowing extended precision of greater precision than 16 bits. 

One particular 16-bit operation may prove of use in certain contexts. This is the 
16- bit addition of the H/L register pair to itself by means of the DADH instruction . 
There are two instances where this variation of 16-bit addition stands out for potential 

utiliy: ^ 

a. Suppose I want to address an extended array of data kept in 2,4,8 or 2 
byte quanta. The shift properties of this addition (it multiplies H/L by 2) can 
be used '^n" times to modify an integer array index ala FORTRAN or PL/1 into 
a useful address offset. 

b. This left shift operation can form the basis of an integer multiply operation. 
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AO-1. 6 A Ceremonial ^*Nit**; 

It serves no good end to act the part of a contentious critic, but. . . at the risk of 
being in the position of a pot calling the kettle black I do protest MITS* use of the 
Anqtdsh Languish (technical dialect) in the Altair 8800 manual I examined recently: 

Implement: This verbalized noun is conventionally used in technical con¬ 
texts such as *‘to implement a system. ” (le: to create the system. ) A 
computer designer implements an LDA or STA instruction; the programmer 
codes said implemented instruction (ie: selects it) as part of his own pro¬ 
cess of implementing a software system. Programmers never use unimple¬ 
mented instructions as a matter of course. (If you take Webster literally 
one might come out with the MITS definition of the term implement . ) 

Variance: A variance exists and is defined in the legalese terminology of 
"obtaining a variance (exception)" to some law by bootlicking and bribing 
the appropriate petty bureaucrats. It is also the square of the standard 
deviation in the terminology of statistics. A variance is not a variation o n 
an instruction's operation, that is unless one wished to redefine conventional 
usage. 


I have been collecting reports from several subscribers on the Altair product and witk^ 
the exception of what appear to be relatively minor technical problems, most purchasers 
of the system indicate satisfaction with the product and service on it. 


ERRATUM: 

Charles S. Lovett receives a one issue subscription extension for being the first sub¬ 
scriber to report an error in the ECS-7 design article of February 1975 ECS. The line 
from pin 2 of IC -14- which is shown connected toground should instead have been a 
. 01 mfd capacitor to ground. (Switch SI would have no effect if wired as drawn.) 


A NOTE CONCERNING THE MOTOROLA 6800 MPU... 

With this issue, I have started to make references to the M6800 MPU system, pri¬ 
marily because I expect it to be available to the Experimenter's Computer System market 
in the near future. I have been in fairly close contact with the local Motorola sales office 
in connection with some hardware/software desigti work I am currently doing, and I have i 
indications that supplies of this product will soon be fairly widely distributed, ‘ 

If you want to find out about the M6800 in detail, I wholeheartedly recommend purchase 
of the M6800 Microprocessor Applications Manual (approximately 700 pages 8.5x 11 @ 

$25. 00) and the M6800 Microprocessor Programming Manual (approximately 250 pages 
@ $10. 00), The applications manual includes lots of useful information including inter¬ 
faces (hardware and software) to floppy discs, cassette tape drives, teletype, Burroughs 
self-scan displays, adding machine tape printers, etc. etc. I have verbal assurances 
from the-local Motorola sales office that these books will be sold to private individus 
request. If you are interested I suggest that you look up the telephone number of the near¬ 
est office and inquire. If you have any problems, let me know and Ill try to make formal 
arrangements to distribute copies. These documents will set the standard for some time 
to come, and would easily serve as the basis of a "software engineering" course in appli¬ 
cations. 
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News & Notes to accompany Volume 1, No. 4 - April 1975. Some further midnight mad¬ 
ness. • . 

FLOPPY DISC DRIVE REPORT: I spent some time talking to Don Whitehead this week 
concerning the floppy disk purchase and its progress. Here is the latest status report 
on the operation: 

a. There is sufficient interest to warrant going through with the purchase as orig¬ 
inally intended . . . BUT . . . 

b. When Don went back to the Memorex representative to make the firm commit¬ 
ment on an order of the drives he found several business points had changed from the 
time of his preliminary arrangements, to whit: 

- The delivery dates are getting pushed steadily back by the manufac¬ 
turer as priority is given to the larger purchasers of the unit. Current 
estimate is June - original was April. 

- Memorex will not allow the technical details of the interface (ie: detailed 
manuals) be distributed for at least six months for competitive reasons. This 
is despite all assurances to the contrary earlier. The demand for a non-dis¬ 
closure agreement effectively rules out distribution of technical specs, thus 
in itself wipingout any possibility of using the Memorex drive. 

c. The individuals sending in the deposits have all had their checks returned for 
the time being, until a new arrangement can be made with an alternate source. 

The idea and intent are not being abandoned due to this setback. Among other things, Don 
wants to locate the source for his own consulting software business. Between now and the 
next progress report, weHl both be doing a bit of research on several other options avail¬ 
able in regard to floppy disk drives. 

JIM FRY INDICATES to me in a letter that he will be repeating the memory IC offer in 
May of this year. Again, his address is Po O. Box 6585, Toledo, Ohio 43612 - write 
him for details on the 2102*s selling new at approximately $5.00. 

PC BOARD FOR ECS-8. After one false start with a vendor who could not deliver, the 
ECS-8 modem PC boards have arrived (April 15) and been shipped to all subscribers. who 
ordered the product. The boards have a layout looking (roughly) like this: (preliminary. ) 




The price is $9. 00 plus postage for 4 ounces (approximate), and there is no discount 
applicable to this item. 

TWO PUBLICATION REFERENCES WHICH MAY BE OF INTEREST TO SUBSCRIBERS: 

Hal Singer (Cabrillo Computer Center, 4350 Constellation Road, Lompoc, Ca. 93436) 
puts out the Micro-8 newsletter, devoted to information concerning the original home¬ 
brew 8008 system of Radio Electronics summer *74. 

The Computer Hobbyist , 520 Sorrel Street, Cay North Carolina 27511 is a publication 
for which I only have an existence proof - several new subscribers referencing a letter 
from Gordon French. 







